home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 9911 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.7 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 4 Mar 1996 18:31:59 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4hg92vINNnat@keats.ugrad.cs.ubc.ca>
  8. References: <JSA.96Feb16135027@organon.com> <4hakfl$ogd@fred.netinfo.com.au> <4hf701INNdl7@keats.ugrad.cs.ubc.ca> <313B44AE.4134@mtm.syr.ge.com>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <313B44AE.4134@mtm.syr.ge.com>,
  12. Steve Howard  <howard@mtm.syr.ge.com> wrote:
  13. >engineers make mistakes (Kazimir excluded, of course ;) ) Ada compilers and the supporting run-time
  14.  
  15. That is not the point at all. I did admit in another message that I made an
  16. embarassing little error in a portion of my project recently, and that I could
  17. have easily maded it were I working in Ada. I have no problem ``parsing'' the
  18. code I have written because I'm very used to C's lexical and syntactic
  19. properties. I understand that some people who came from a COBOL background are
  20. resistant to a language which calls for a character set of 96 symbols, and for
  21. this reason is surely conducive to errors.
  22.  
  23. >systems help to identify these problems early on.
  24.  
  25. It would not have helped with this particular error. There was no type
  26. mismatching, no overrun boundaries, no heap corruption or address violations.
  27. Just a straight forward incorrect computation. The testers discovered the weird
  28. results, and the cause still took a while to discover.
  29.  
  30. If C is so prone to errors, why isn't the same program plagued by runaway
  31. pointers, heap corruption and other nasties? After all, we C idiots can't write
  32. ten lines of code without introducing such problems, right?
  33. -- 
  34.  
  35.